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ABSTRACT 

This document describes operations associated with a set 
of flight experiments and demonstrations using a Boeing- 
757-200 (B -757) research aircraft as part of low visibility 
landing and surface operations (LVLASO) research 
activities. To support this experiment, the B -757 
performed flight and taxi operations at the Hartsfield- 
Atlanta International Airport (ATL) in Atlanta, GA . The 
B -757 was equipped with experimental displays that were 
designed to provide flight crews with sufficient 
information to enable safe, expedient surface operations in 
any weather condition down to a runway visual range 
(RVR) of 300 feet. In addition to flight deck displays and 
supporting equipment onboard the B -757, there was also 
a ground-based component of the system that provided for 
ground controller inputs and surveillance of airport surface 
movements. The integrated ground and airborne 
components resulted in a system that has the potential to 
significantly improve the safety and efficiency of airport 
surface movements particularly as weather conditions 
deteriorate. Several advanced technologies were employed 
to show the validity of the operational concept at a major 
airport facility, to validate flight simulation findings, and 
to assess each of the individual technologies' performance 
in an airport environment. Results show that while the 


maturity of some of the technologies does not permit 
immediate implementation, the operational concept is 
valid and the performance is more than adequate in many 
areas. 

1.0 INTRODUCTION 

In general, the LVLASO research is aimed at 
investigating technology as a means to improve the safety 
and efficiency of aircraft movements on the surface during 
the operational phases of roll-out, turn-off, inbound taxi, 
and outbound taxi. This investigation becomes critical in 
the face of growing demands for air travel, the increasing 
number of reported surface incidents (287 in 1996) and 
fatal accidents (five since 1990), and the economic, 
environmental, and geographic infeasibility of 
constructing new airports and/or runways. The goal of 
this research, which began in 1993, is to investigate 
technology as a means of making better use of existing 
runways and ideally, enablesafeVM C capacities (i.e. flow 
rates) on the surface in weather conditions down to a 
visibility of 300'. 

Specifically, the objectives of this flight test were (1) to 
demonstrate a prototype system that has the potential to 
meet the LVLASO goal, (2) to validate selected 
simulation findings and the operational concept at a major 
airport facility, and (3) to assess the performance and 
suitability of the prototype as compared to the operational 
requirements of an Advanced Surface M ovement Guidance 
and Control System (A-SM GCS) [1], as well as the 
requirements of NASA’s conceptual system. 

The architecture defined for the prototype LV LA SO 
system tested at ATL was derived from three constraints: 
do not add workload to the users of the system (i.e. pilots 
and controllers); focus on the needs of the users in IM C 
conditions, or at night, where hazardous situations are 
more likely and movements tend to slow down; and 
finally, makeevery effort to use technologies that are 



either already part of the National Airspace System (NAS) 
or are planned to be in the NAS. 

In order to operate safely in poor weather conditions at 
rates equal to those accomplished in clear weather, both 
pilots and controllers must be provided with information 
about the state of the airport environment. Assuming a 
fully operational aircraft, there are primarily three types of 
information required by the pilot to safely control the 
movement of the aircraft while avoiding an 
accident/incident on the airport surface. These are (1) 
continuous awareness of position, (2) continuous 
awareness of traffic or obstacle positions that may impede 
progressing to the destination, and (3) an understanding of 
the path to follow from current position to the desired 
destination. In the airport environment, controllers have 
similar needs when handling traffic on the surface, except 
they need to know (1), (2), and (3) for all vehicles . 
Controllers also have the responsibility of providing the 
route to all the vehicles/aircraft on the surface movement 
area. 

Currently, position awareness on the surface is determined 
by both pilots and controllers by way of visual scans of 
the outside scene and, to a lesser degree, radio 
communications to confirm position. I n most cases, 
painted centerlines and markings, airfield lights, and 
signage provide adequate information to crews to safely 
determine position. Occasional reference to a paper chart 
may also be done to get a "global" awareness of position, 
particularly at unfamiliar airports. T raffic and obstacles 
are also picked up via visual scan of the outside scene. 

The Traffic Alerting and Collision Avoidance (TCAS) 
system [2], which provides traffic information to pilots 
while airborne, is not currently used on the surface. The 
Airport Surface Detection Equipment (ASDE-3) radar is 
available at some airports and provides controllers with 
surface traffic positions on a radar screen. However, flight 
crews are not provided with this radar information. I n 
addition, current ASDE-3 radars do not identify or track 
aircraft and can report "false" targets. Finally, the path to 
follow, or route, is provided via a voice channel to the 
crew by theairtraffic controller, usually a specific 
"ground controller". The ground controller must 
maintain a mental picture of the routes given to all aircraft 
to avoid directing them into an unsafe position on the 
surface. M eanwhile, the crew must either memorize this 
path or write it down then follow the signage to the 
destination ramp or runway. Routes are read-back over 
the radio by the pilot as a means of confirmation. 

Based on the significant dependence on visual scans, the 
ability to maintain situational awareness as the visibility 
drops, or even at night, becomes difficult because of 
growing uncertainties of position, obstacles/traffic, and 
even the path. This is especially true at unfamiliar 
airports. These uncertainties can cause pilots to slow 
down until the uncertainty is reduced to a comfortable 
level, or cause them to continue at the same speed but 
with reduced confidence and safety margin. Also, 


dependence on voice communication as a sole source of 
route information can be unsafe due to the possibility of 
miscommunication or misunderstanding on the part of the 
pilot or the controller. 

The system flight tested in Atlanta is an attempt to show 
how technology can be used in the near term to reduce the 
uncertainties mentioned above for both controllers and 
pilots. As will be shown, these uncertainties are reduced 
by providing them with supplemental guidance and 
situational information. This information is provided in a 
natural manner such that it reinforces any cues that are 
available and replaces those that are not available. 

The system is based on several pieces of prior and related 
work. It is primarily based on "lessons-learned" in flight 
simulation studies both at NASA-LaRC [3], and at 
NASA-ARC [4]; a flight test performed attheFAA 
Technical Center in 1995 [5]; and two draft requirements 
documents [1] [6], ICAO has sponsored the development 
of operational requirements for A-SM GCS [1] to describe 
a modular system consisting of several functions 
supporting safe, expeditious movement of aircraft and 
vehicles on the airport surface in all visibility conditions. 
Because the goals of A-SM GCS and the LVLASO 
research are so closely related, references to theA-SM GCS 
requirements will be made frequently in this document. 
The reader is encouraged to obtain a copy of [1], 

2.0 SYSTEM DESCRIPTION 

The system flight tested atATL can be decomposed into 
surveillance, guidance, control, and routing functions as 
has been donefor A-SM GCS. Also, itcan be 
decomposed into the airborne and ground subsystems. 
Finally, itcan be decomposed by operational phase (e.g. 
landing, roll-out, turn-off, taxi). Each of these 
decompositions will be referred to in this paper to 
describe the LVLASO system. 

Physically, the prototype surface operations system 
consisted of both ground and flight components that were 
integrated via three digital datalinks as well as the normal 
voice channels. The flight system provided the flight 
crew with enhanced guidance and situational awareness 
information through the use of a head-up display (HUD) 
and a liquid-crystal display (LCD) which were added to 
the flight deck of the B -757. These displays were 
integrated with onboard sensors and datalinks that 
provided the necessary input data to the displays as well 
as providing aircraft state data to the ground components. 
The displays were designed to function based on the 
phase of flight. During high-speed roll-out and runway 
exit, the Roll-OutT urn-Off (ROTO) display symbologies 
and functions were engaged [7], During taxi, the Taxi 
Navigation and Situational Awareness (T-NASA) display 
symbologies and functions were engaged [4], Regardless 
of the phase of flight, the information presented on the 
displays was intended to supplement missing visual cues 
in low visibility situations or at night, and to reinforce 



any available visual cues that may have an uncertainty 
associated with them (e.g. sign directional arrows, traffic 
positions, path to follow, etc.). 

Similarly, ground-based components of the system 
provided the controller with supplemental information 
about traffic (e.g. position, identity, and intent), as well as 
a means for communicating with tine flight crew overa 
digital link, in parallel with the normal voice channel. 

As with the flight crew, the information provided is meant 
to supplement missing visual cues and to reinforce 
uncertainties associated with whatever visual cues are 
available. 

Functionally, the surveillance function is implemented on 
the ground (as described in 2.2), with its outputs being 
provided to the guidance, control, and routing functions. 
The guidance function provides advisory information to 
the vehicle/aircraft operator with inputs from the other 
functions. Control and routing functions are performed 
on the ground. Figure 1 shows how these functions 
relate and the data exchanged between them using the 
ATL architecture as a basis. 


position and identity 
of all targets » 



Figure 1. System Functional Decomposition. 

From [1], surveillance is defined as a function that 
captures identification and positional information on 
aircraft, vehicles, and objects within a specific area. 

Control is defined as a function that applies measures for 
preventing collisions, runway incursions, and ensuring 
safe, expeditious, and efficient movement. Routing is 
defined as the planning and assignment of 
a route to individual aircraft and vehicles to allow safe, 
expeditious and efficient movement from its current 
position to its intended position. Finally, guidance is 
defined as necessary advisory information provided in a 
continuous unambiguous reliable manner such that pilots 
and/or vehicle operators can steer their aircraft or vehicle 
along the assigned route while maintaining an appropriate 
velocity. 


2.1 FLIGHT SYSTEM 

As mentioned previously, the ATL testing was 
conducted using a B -757 research aircraft. M odifications 
to the flight deck included installation of three hardware 
devices (figure 2). 



A FI U D device was mounted to be used from the left seat 
position. T he H U D consisted of a projector, mounted 
above and behind the pilot, and a combiner glass 
mounted between the pilot's eyepoint and the front left 
windscreen. This specific Fill D was manufactured by 
Flight Dynamics, Inc. and was capable of projecting a 
holographic image onto the combiner based on a raster- 
type graphics input. The field of view was 30 degrees 
horizontal by 24 degrees vertical. T he H U D was used to 
support the guidance function of the experimental system 
as described in 2.3. 

An active matrix LCD device was mounted under the 
glare shield and was used to render the moving map 
symbologies described in 2.3. This LCD was 
manufactured by R ockwel l-C ol I i ns. The LCD was 
sunlight readable and provided 1024x768 pixel 
resolution. The viewing area was 8"x6" and had a 65 
degree horizontal viewing angle which allowed for 
viewing by both crew members. 

A Pilot Input Device (PI D) was mounted on the center 
aisle stand. The PID allowed the pilots to control the 
experimental displays. The controls are described in 2.3. 

Aft of the flight deck, pallet workstations contained the 
necessary on-board systems required for data recording, 
power, datalink, and display generation. Figure 3 depicts 
the experimental flight system. 



Figure 3. Experimental Flight System. 

Two V FI F data radios and their supporting antennas were 
provided by R ockwel I -C ol I i ns and were set to operate in 
receive mode only. The first of the two was responsible 
for receiving DGPS corrections and forwarding them to 
theGPS receiver. The second radio was responsible for 
receiving traffic and runway status information provided 
by the ground-based surveillance system. This data was 
then forwarded to the I/O processor for eventual display 
on the LCD as described in 2.3. The radios employed 
the Differentially encoded 8-Phase Key Shifting (D8PSK) 
modulation waveform and adhered the RT CA standard 
protocol DO-217 [8], 


velocity and acceleration values. Once the filter is 
initialized, each input of GPS data is saved and 
propagated forward using the velocity estimates. Each 
subsequent input is compared to the propagated value of 
the previous input, and rejected if it differs by more than a 
preset limit. If the data is valid and passes this limit test, 
it is differenced with the saved value of the filter position 
output corresponding to the age of the current G PS 
position. The difference vector is then input to the 
complementary filter to correct the position estimate. 

This resulting position estimate is that of the CG of the 
aircraft. With GPS data valid, Differential GPS available 
(DGPS) and acceptable H D 0 P and VDOP, the filter is 
checked for convergence. Once the average length of the 
difference vector has converged, a flag is set and the 
display system is permitted to use the derived position 
estimate. This flag remains set so long as valid data 
continues to be received. If this flag was not set, the 
experimental displays would alert the pilot(s) that the 
position report is not valid. This was done by flashing 
the text "DGPS INVALID” on both displays. 

An independent GPS system was employed using an 
Ashtech Z-12 receiver. This system recorded GPS data 
and, along with data stored at the ground site (see 2.2), 
allowed for post- processing that resulted in nominal 5cm 
accurate position data [11], This data was used to 
evaluate the accuracy of the experimental real-time 
position determining system described above. The two 
GPS receivers on the aircraft shared the same antenna. 

2.2 GROUND-BASED SY STEM 


A modified M ode-S transceiver broadcast GPS position 
reports, also known as Automatic Dependent Surveillance 
Broadcast (AD S-B), to the ground-based surveillance 
system as well as supporting the bi-directional 
Controller-Pilot Datalink Communications (CPDLC). 
CPDLC format adhered to the RTC A standard protocol 
DO-219 [9], CPDLC messages were forwarded to the I/O 
processor for eventual display as described in 2.3. 

The I/O processor was responsible for reformatting data 
received by the experimental datalinksand providing it to 
the display computers. This processor also relayed data 
to be downlinked to the test controller at the ground site 
via the M ode-S transceiver. Finally, the unit integrated 
DGPS and IRU position data and provided itto the 
display computers. Blending of DGPS and IRU position 
data was critical to ensure a continuous position update 
on the two experimental displays and to minimize the 
variance of the position reports. Without a blending 
function, the displays would "jump” at a 1 Hz rate and be 
distracting to the pilots. Also, this blending allowed for 
intermittent outages of the DGPS system. 

As described in [10], the GPS position data from the 
Collins' GPS receiver was input into the I/O processor 
and passed through a complementary filter to produce 
GPS derived position. This filter was initialized to I RU 


The ground-based subsystem, illustrated in figure 4, 
included the surveillance, control, and routing functions. 
It also enabled the transfer of required information among 
the ground components and to/from the B -757 via 
datalink. Equipment was located at two sites at ATL : 
the control tower, and atop the Renaissance FI otel just 
north of the movement area. 
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Figure 4. Experimental Ground-Based System. 

The surveillance system development was led by the 
Federal Aviation Administration (FAA) and consisted of 
four primary elements that were integrated in an attempt 






to provide full coverage of the airport surface, to provide 
identity information to both pilots and controllers, and to 
collect data so that multipath mitigation algorithms can 
be developed. Requirements for a surveillance function 
are listed in [1], The elements of the surveillance function 
used for the ATL testing were: 

The Airport Surface Detection Equipment (ASDE-3) 
captured position data (range and azimuth) for all aircraft 
or vehicles operating on the airport surface movement area 
at a one hertz rate. ASDE-3 is a radar operating in the 
Ku-band (15.7 - 16.2 Ghz). ASDE-3 does not require any 
equipage on aircraft or vehicles and iscapableof detecting 
targets with a cross section as small as three meters. Its 
range is specified to be 24,000 feet in all directions on the 
surface and up to 200' above the surface. ASDE-3 and its 
associated display is scheduled for deployment at 40 
airports over the next four years. Although ASDE-3 isa 
high performance radar system, it does have certain 
limitations. ASDE-3 has a 500' "cone-of-silence" area 
encircling the antenna. T argets in this area are not visible 
by ASDE-3. In fact, at ATL, taxiway Dixie passes 
through this cone of silence (figure 5). Aircraft taxing on 
Dixie disappear from the ASDE-3 display while in this 
cone of silence. Further, there can be other coverage gaps 
with particular ASDE-3 installations as it is a line-of- 
sight radar. For example, at ATL, the section of Echo 
running parallel to RWY 26L on the east end of the 
airport is not covered by ASDE-3 because of a "FLY 
DELTA" sign. Because of this issue, siting of the 
ASDE-3 is critical to ensure maximum coverage. Also, 
ASDE-3 is susceptibleto multi-path reports. Energy 
pulses emanating from the radar can return after reflecting 
off several mediums along its path. This can result in a 
false target being reported and possibly displayed. 

Finally, ASDE-3 does not report target identity 
information. It is because of these three issues (coverage, 
multi-path, and identification), that the other surveillance 
systems described below were integrated with ASDE-3 for 
this testing to hopefully ensure full coverage, minimal 
multi-paths, and identification which are required in [1], 

The A i rport Surface T arget I dentifi cation System 
(ATIDS) captured position and identity data for aircraft 
and ground vehicles equipped with ADS-B and/or M ode- 
S transponders. At ATL, ATIDS utilized five fixed 
receiver/transmitters (R/Ts) located on the north side of 
the airport (figure 5). These R/Ts performed a 
multi lateration function [12] on targets emanating a 
M ode-S beacon. The result of this multi lateration 
function was the position and identity of any equipped 
target with its M ode-S transponder operating. In 
addition, ATIDS captured the ADS-B transmissions 
emanating from the B -757 at any or all of its five R/T 
sites. ADS-B transmissions include position and identity 
information [13]. All position and identity data captured 
by ATIDS, in addition to data it acquired from the FPU 
(described below), wasforwarded to the AM ASS 
computer (described below) for "fusion" with the data 
from the other surveillance sensors. The ATIDS update 


rate was specified to be one hertz. The coverage area for 
the ATL ATIDS was specified to be only on the north 
side of ATL out to 500’ beyond the approach end of the 
runways and up to 500’ above the surface. 
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Figure 5. ATL Airport Layout. 


The Airport M ovement Area Safety System (AM ASS) 
provided the following: (a) tracking of ASDE-3 targets; 

(b) data fusion of ATIDS target data (captured via 
multi lateration or ADS-B) with ASDE-3 track data, and 

(c) safety logic to detect runway incursions and alert 
controllers and the test pilots. A M ASS has been 
designed to visually and aurally prompt controllers to 
respond to situations which potentially compromise 
safety. AM ASS was also responsible for passing target 
information and runway status to a datalink manager 
(DM ) for forwarding to the B -757. Runway status 
information consisted of hold lines drawn along the 
runway edge lines at locations where taxiways intersect 
the runway. These lines turned red (on both the 
controller and cockpit display) when high speed runway 
traffic (either landing or taking off) was approaching a 
specific intersection. These red lines turned off after the 
aircraft/vehicle passed the intersection. By knowing the 
runway status, pilots are less likely to enter the runway at 
an unsafe time. 


A Flight Plan Unit (FPU) provided a transparent interface 
to the A RTS-1 1 1 A system database. This allowed ATIDS 
to extract the M ode-A code, the aircraft call sign, and the 
aircraft type from the database, in real-time, and associate 
this information with specific M ode-S transmissions 
received. All retrieved information was forwarded to 
AM ASS for use by the fusion function. 

This resulting fused surveillance data was provided to and 
displayed on both the test ground controller display 
(described below) and the B-757's experimental LCD . 
This enabled both the pilots of the B -757 and the 
controller to have the same “picture" of the airport surface 
traffic at any point in time. This is a requirement 
specified in [1], 


Supporting the guidance function (as well as the ADS-B 
portion of the surveillance function) of the system, a GPS 
ground station was implemented to provide differential 
corrections. This ground station operated independently 
of all other systems. It consisted of two GPS receivers 
andaVHF data radio. These three components were 
identical to those used onboard the research aircraft. One 
of the two GPS receivers was an Ashtech Z-12 that was 
responsible for storing data that could be used subsequent 
to the flights to obtain high accuracy truth data. The 
other was the Rockwell -Col I ins GPS receiver that 
operated in conjunction with theD8PSK radio transmitter 
to fully implement the RTC A DO-217 specification [8], 

TheDM was responsible for converting surveillance 
system data received from AM ASS into the protocol 
required by the D8PSK transmitter. TheDM was 
designed to be able to support multiple transmitter types 
simultaneously such that aircraft/vehicles with different 
receivers could acquire the traffic broadcast. Thisenables 
alternate datalinks to be utilized. 

Supporting the routing and control functions of the 
system, a Controller Interface (Cl) allowed a test 
controller to mimic normal voice instructions in parallel, 
and then transmit these instructions digitally for display 
in theflight deck of the B -757. The Cl is described in 
more detail in 2.3.3. 

2.3 DISPLAY SYMBOLOGIES 

2.3.1 MOVING MAP LCD 

The experimental LCD onboard the B -757 provided both 
crewmembers with: 

• depiction of the airport layout; 

• depiction of current position/heading of the B -757; 

• depiction of current position of other traffic; 

• display of ATC instructions including the taxi route; 

• display of runway status. 

See figure 6 for a depiction of the LCD map symbologies 
used at ATL . This format is part of the Taxiway 
Navigation and Situational Awareness (T-NASA) system 
that has undergone human factors testing in several 
simulation studies [4][14][15]. In addition to the input 
data received from the datalinks and the DG PS/I RU 
system onboard, an accurate airport database was also 
required. This database was provided byjeppesen- 
Sanderson and included all run way/taxi way edges and 
centerlines as well as hold-short lines. These were all 
required to be accurate to one foot. 



Figure 6. ATL M ap LCD Symbologies. 

Using the PI D , the flight crew wasableto selectfrom six 
zoom levels, one of which was an overview of the airport. 
The airport overview zoom level was north up while all 
other zoom levels were track up. The crew also had the 
choice to display symbols for other traffic and, if traffic 
was displayed, show traffic identification labels, if desired. 
The capability also existed to scroll through the list of 
ATC instructions displayed in the bottom portion of the 
map LCD. 

in addition to rendering the display, the map computer 
generated downlink messages that were relayed to the test 
controller at the ground site. For example, if the B -757 
deviated from the route issued by ATC, a message was 
sent to the test controller alerting him of this deviation. 
Similarly, if the B -757 returned to its approved path, a 
"taxi route resolved" message was sent to the test 
controller. 

Along with the normal activities associated with 
operati ng the ai rcraft on the surface, the map LCD 
symbologies supported the guidance function of the 
system and was provided to remove guidance/navigation 
uncertainties that can become substantial in lower 
visibilities and at night. The display does this primarily 
by increasing the crew's situational awareness. 






2.3.2 ROLL-OUT, TURN-OFF, AND TAXI 
GUIDANCE HUD 


On the HU D, from final approach until the B -757 had 
safely exited the runway, the roll-out and turn-off (ROTO) 
symbologies were enabled. Specifically, while in the 
landing phase, the ROTO system displayed symbology 
similar to the symbology found on commercial HUD 
systems designed to provide landing guidance. During 
the final approach, the pilot selected an exit using the 
PID . The exit chosen was displayed on the H U D in a 
box in the upper right-hand portion of the display. Along 
with the exit chosen, the box also listed the desired exit 
speed and the estimated distance from the projected 
touchdown point to the exit. Once the aircraft landed and 
the nose strut was compressed, the symbology 
transitioned from the in-flight symbology to the roll-out 
and turn-off guidance symbology (figure 7). While rolling 
out, the symbologies presented attempt to reinforce visual 
cues that may be difficult to see(i.e. runway edges and 
runway remaining markers) as well as provide a 
deceleration profile to follow that will minimize runway 
occupancy time to the chosen exit. In particular, the 
velocity error bar on the left wing of the velocity vector 
symbol and the projected exit speed listed on the left tells 
the pilot, at any point in time, whether he is moving too 
fast or too slow to make the exit at the desired speed. By 
following the profile and adjusting his speed as he 
approaches the exit, the pilot will be able to take the exit 
at the desired speed. Again, these symbols are provided 
so that the pilot can maintain or reduce VM C roll-out 
turn-off times in IM C conditions or at night. 
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Figure 7. Roll-out T urn-off HUD Symbols. 
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Figure 8. Taxi HUD Symbology. 

All HUD symbols were displayed relative to the pilot’s 
eye reference point such that they overlaid the outside 
scene (e.g. the painted centerline stripe). The taxi HUD 
display format is part of theT-NASA system that has 
undergone human factors testing in several simulation 
studies [4][14][15j. 

Along with the normal activities associated with 
operating the aircraft on the surface, the HU D symbologies 
supported the guidance function of the system and was 
provided to remove guidance/navigation uncertainties that 
can become substantial in lower visibilities and at night. 

2.3.3 CONTROLLER INTERFACE 

During the testing, a ground controller located at a test 
site had access to a controller interface (Cl) in addition to 
his normal visual scans and voice communications. The 
Cl provided: 

• electronic flight strips updated in real-time; 

• continuous display of surface traffic positions and 
identification on an airport map; 

• controller instruction capture and datalink to the B- 
757 via voice recognition or touchscreen; 

• alerts of route deviation by the B -757; 

• runway exit taken by the B -757. 

See [16] for a detailed description of the Cl . 


As the taxi route was delivered by the test controller after 
exiting the runway, the symbology transitioned from the 
ROTO mode to the taxi mode. The taxi symbols are 
shown in figure 8. 


3.0 FLIGHT TEST OPERATIONS 

The deployment to ATL occurred in two separate sessions, 

J uly 31 to A ugust 8, and A ugust 18 to A ugust 29, 1997. 
The first session included end-to-end operational checks of all 
systems. Also, during this session, all flight tests using 
NASA test pilots as subjects were completed. The second 
session consisted of flight tests (using commercial B -757 
captains as subjects) and demonstrations for visitors from the 
aviation community. 



Because theCI was at the prototype stage, a test controller 
was used. This controller was located at the ground site (not 
in the tower cab) and monitored ATL ATC communications. 
Any verbal instructions designated for the B -757 were sent 
electronically, in parallel, to the aircraft via datalink and the 
voice recognition function of the Cl . These were then 
displayed on the two experimental flight deck displays as 
described in 2.3. 

The crew were instructed to utilize the H U D and map LCD, 
while maneuvering the B -757, on an as-needed basis. The 
HUD was to be used by the captain for supplemental guidance 
cues and enhanced situational awareness. The map LCD was 
to be used primarily by the first officer for situational 
awareness which could then be relayed to the captain if 
necessary. The captain could refer to the map LCD if desired. 
During test runs, the flight crew could manipulate the map 
LCD using thePID as desired (scroll through ATC messages, 
display traffic and labels, and change the field of view). 
Specific details on how to use the LVLASO display system 
were provided as part of each pilots' training procedure prior 
to the flight experiment. 

3.1 FLIGHT TEST PROCEDURE 

All flight test runs began in the ramp area located at the Fixed 
Base Operator (F BO) just north of runway 8L/26R (see figure 
5). At start, the responsible flight deck crew member called 
for taxi instructions from ATL ATC. Once ATC verbally 
relayed the taxi instructions to the B -757, the test controller 
repeated those instructions verbally into the voice recognition 
system and they were sent electronically to the B -757 for 
display on the experimental displays. The captain then taxied 
to the designated departure runway. After taking the runway, 
the B -757 would either (1) takeoff/ci rcl e/I and or (2) taxi down 
the runway depending on the test run. Once clear of the 
runway, the B -757 verbally received a taxi instruction from 
ATC. Again, this taxi instruction was sent to the B -757 by 
the test controller in parallel. After the crew acknowledged 
receipt of the instruction, the captain taxied back to the FBO 
ramp area following the designated path. W hile taxiing, the 
captain was instructed to taxi at a normal taxi rate or higher if 
he felt safety was not being compromised. 

If a specific run included a landing, an ILS autoland was 
used to minimize the touchdown dispersion. On 
approach, the captai n woul d choose the exit usi ng the 
PID. After touchdown and the nose strut was 
compressed, the captain disengaged the autopilot and 
manually performed the roll-out and turnoff procedure 
following the ROTO guidance symbology on the HUD. 

If a takeoff was not required for a specific test run, the B- 
757 taxied down the runway and exited as directed by 
ATC. The ROTO system was not part of these runs. 

These runs were performed to evaluate only the taxi 
guidance system onboard (T-NASA). 


3.2 TEST MATRIX 

Tests were defined to fulfill the goals of the testing while 
staying within the constraints placed on the deployment 
in terms of time and operational costs. The test variables 
were: time of day (day/night), HUD state (on/off), LCD 
state (on/off), left-seat captain, landing required or taxi- 
only, exit chosen, and southside or northside operation. 
Tests runs were done predominantly at night as this more 
closely represents a "low visibility” condition. A total of 
53 test runs were successfully completed which resulted in 
1378 minutes of audio, video, and digital data. The 
average run time was 26 minutes. 

4.0 RESULTS 

W hile the primary objective of this effort was to 
demonstrate the feasibility of the operational concept ata 
major airport facility, secondary objectives were to obtain 
data to (1) validate simulation findings and the 
operational concept, and (2) assess the performance of the 
individual technologies and the system as a whole. 

M eeting these objectives has been done using both 
qualitative (subjective) data and quantitative recorded 
digital data. 

4.1 RECORDED DATA 

During the testing, data was taken in several formats. 

Test pilots and demonstration visitors completed 
questionnaires to obtain their expert, albeit subjective, 
opinion of the system as implemented in Atlanta. A Iso, 
audio/video recordings of all camera images and the 
experimental displays were made of each test run. This 
allowed for review of specific events, either noted while 
reviewing the questionnaire responses, or, while 
reviewing the recorded digital data. Finally, digital data 
was recorded onboard the B -757 and on five systems on 
the ground: the Cl, AM ASS, AT IDS, the DM , and the 
DGPS ground station. All digital data was timestamped 
using the GPS time reference. 

4.2 QUALITATIVE RESULTS 

Validating the feasibility of the system concept has been 
accomplished, in part, by obtaining qualitative 
questionnaire data and comments from test pilots during 
data collection runs and visitors from the aviation 
community during the demonstration runs. Comments 
were also obtained from air traffic controllers that viewed 
the ATL testing. 87 of the 110 attendees completed a 
brief questionnaire. The vast majority of the visitors 
either agreed or strongly agreed that these technologies 
would help enhance both capacity and safety on the airport 
surface. A detailed analysis of the subjective data will be 
published in a separate report. Finally, it should be noted 
that simply operating the system (including the B -757) 
through this series of tests in the environment of a busy 
international airport facility and not negatively impacting 



normal operations substantiates the operational concept 
to some degree. 

4.3 QUANTITATIVE RESULTS 

In order to assess the system performance as well as the 
performance of individual technologies, metrics have been 
defined which can be quantified using recorded data. 
Assessment of the prototype system includes evaluation of 
each major subsystem: 

• flight deck displays 

• datalinks 

• onboard position determination system 

• surveillance system 

• controller interface 

4.3.1 FLIGHT DECK DISPLAY PERFORMANCE 

A large part of the assessment of the flight deck displays 
involves assessment of the effectiveness of the man- 
machine interface during the testing. This analysis is 
being done by our partners at NASA -Ames Research 
Center and will be reported in a separate document. 
However, display performance can also be characterized by 
the update rates and the latencies associated with the 
symbologies being presented to the crew. Failure rates of 
displays are also important, however, for this testing, 
there were no failures of the display system. This does 
not imply that the displays had a failure rate of zero, 
simply that they did not fail over the relatively short 
period of testing in Atlanta. For example, the advertised 
failure rate of the HU D was 8000 hours, while the total 
duration of all flight tests at ATL was just over 23 hours. 

With the exception of the taxi route (which was displayed 
as it arrived), all HUD symbologies were updated at 10- 
15 hertz depending on the amount of symbologies being 
presented at any point in time during the flight. B -757 
position and heading information presented on the map 
LCD were updated at 25 hertz. T raffic and runway status 
data were updated at one hertz. Controller instructions 
arriving via the CPDLC datalink for display on the map 
LCD were updated as they arrived. 

Latency is the delay associated with processing 
information. The only significant latency observed was 
that associated with the traffic data. The ground-based 
surveillance system could take as long as one second to 
"scan" the airfield for traffic before it forwarded the entire 
scan of data to the B -757. Onboard, the I/O processor 
waited until it had received a full scan of traffic before it 
forwarded it to the display system. This took up to one 
additional second if traffic conditions were heavy and the 
datalink became loaded. Thus, the latency for the display 
of traffic data on the map LCD varied between one and 
two seconds depending on the number of targets on the 
airport surface. For the largest number of targets that 
occurred during the testing (47), the latency was ~2 
seconds. A Iternate means of data processing could 
improve this latency (e.g. draw every target report as it is 


received). Latencies for drawing all other symbologies 
were near zero (i.e. not measurable). 

4.3.2 DATALINK SYSTEM PERFORMANCE 

Datalink performance can be quantified using several 
metrics. These include coverage, signal strength, and 
availability. Coverage is defined hereto be the surface 
area over which the datalink performed correctly (as 
specified). Signal strength is the amount of signal 
detected at the receiver at a specific range from the 
transmitter. Availability will be defined as the fraction of 
time that the datalink was operating correctly (as 
specified) during any given time interval. 

The four datalinks utilized at ATL were the VHF datalink 
for DGPS corrections, the VHF datalink for traffic data , 
theCPDLC datalink, and theADS-B datalink. 

VHF Datalink Performance 

Datalink performance was characterized for the VHF 
datalinks onboard the B -757 by recording DGPS position 
and datalink message status outputs from the GPS 
receiver; and also by recording received signal strength 
outputs based on internal receiver Automatic Gain 
Control (AGC) information from the VHF DGPS datalink 
receiver. Three states of message status were recorded: 

(1) no message received, (2) message received but CRC 
failed, and (3) message received and CRC passed 
successfully indicating a correctly received message. 
Because the two VHF datalink applications (corrections 
and traffic) utilized identical hardware and an identical 
protocol (DO-217), an independent evaluation of the traffic 
datalink will not be presented here. The only difference 
was the specific application data placed in the messages. 

Coverage was excellent on the airport surface as well as in 
the pattern out to about 10 nmi. Signal strengths ranged 
from -67 to -77 dBm in this area which is also very good. 
During flights to/from ATL, the range was observed to be 
~70 nmi. During flights R062 through R066, the total 
number of messages transmitted was 42204. Of these, 
42115 were correctly received (99.79%). 68 of 42204 
were garbled (0.16%) and 21 of 42204 were not received 
at all (0.05%). Only once was there a three second outage 
and only three times was there a two second outage. All 
other outages were one second in duration. 

The effective bandwidth utilized for the VHF datalinks can 
also be quantified. Because the traffic datalink requires the 
most bandwidth and is dependent on current traffic 
conditions, it can have the most impact on system 
performance. F or these tests, the maximum number of 
targets seen by the surveillance system at any time was 
47. This translated to 6256 bits of data to be transmitted 
i n one second usi ng the message format def i ned for these 
tests. This represents only 20% of the specified 31500 
bits per second budget. The DGPS corrections messages 
used less than one third of one of theeightTDM A slots 



as per DO-217 [8] and ARINC 743A [17]. Only 112 + 
48n bits per second (where n is the number of satellites) of 
the 31500 bits per second bandwidth budget were utilized 
for DGPS corrections. Even for 12 satellites, this is only 
688 bits per second. 

CPDLC Datal ink Performance 

Because controller-pilot datalink messages were very short 
and infrequent, the primary metric of interest is the 
percentage of messages that were lost in transmission. 

For the entire testing period, 97% (516/534) of the 
CPDLC downlink messages (e.g. "Roger") from the B- 
757 were correctly received by the test controller. 92% 
(432/470) of the CPDLC uplink messages (e.g. "T axi to 
RWY 8L via Alpha”) sent by the test controller to the B- 
757 were correctly received. This is very good 
performance considering the fact that two modems had to 
be used to transfer messages to/from the two ground sites 
prior to transmission to/from the B -757 over the M ode-S 
link. 

ADS-B Datalink Performance 

This specific issue is of paramount importance to the 
aviation community as the current NAS plans suggest 
possible world-wide equipage with ADS-B capability in 
the future [13], As with any new technology with such a 
scope, there are a multitude of metrics that must be 
quantified to ensure safe robust use in the NAS. 

Examples are coverage, capacity, update rate, and 
transmission waveform and frequency. W ith only one 
ADS-B participant for these tests at ATL, most of these 
issues could not be addressed. However, Rannoch 
Corporation has been tasked with assessing the ADS-B 
performance observed at ATL. This will be published in 
a separate report. One metric that has been quantified is 
the error-free ADS-B reception percentage. Tablel shows 
the ADS-B reception percentages for four representative 
flight days at ATL along with the overall performance. 


Jable 1. _Error -free ADS-B Reception. 


Flight# 

EFSR 

EXSR 

% 

R055 

3278 

3343 

98.1 

R056 

8330 

8539 

97.6 

R057 

6276 

6438 

97.5 

R058 

4630 

4778 

96.9 

Overall 

51050 

52870 

96.6 


EX SR is the expected squittersto be received (i.e. two 
per second) and EFSR is the error-free squitters received 
by at least one of the five ground-based R/T s at ATL . 


4.3.3 ON-BOARD POSITION DETERMINATION 
PERFORMANCE 

Determining the position of the B -757 onboard and in 
real-time was accomplished using inputs from the DGPS 
system and the Inertial Reference U nit (IRU) as described 
in 2.1. Several metrics can be defined related to the 
accuracy of the position reports. These include the root- 
mean-square (RM S) error, the cross track error , and the 
along track error . I n addition, horizontal and vertical 
dilution of precision (HDOP and VDOP) values are 
produced by the G PS receiver. These metrics are 
summarized in table 2. Only surface data is used and as 
such the RM S error is only calculated for the horizontal 
plane (i.e. altitude errors are not included). Finally, a 
valid DGPS solution was produced and available for 
41379 of the 41715 seconds considered when generating 
table 2. This constituted 99.2% availability for this time 
interval. 


Table 2. DG PS Performance. 


M etric 

M ean 

StDev 

RMS (m) 

0.78 

0.52 

Cross track (m) 

-0.04 

0.60 

Along track (m) 

0.07 

0.72 

HDOP 

1.51 

0.19 

VDOP 

-2.20 

0.34 


it is important to note that the real-time position observed 
by the flight crew on the experimental displays (both the 
HUD and the LCD) was derived from the raw DGPS 
sensor data (presented in table 2) and data coming from 
the IRU . The result of this "blending” function was a 
robust, continuous update (25 Hz) that removed much of 
the "noisy" behavior of the raw DGPS updates. The 
DGPS/IRU solution converged to the mean error while at 
the same time minimized the variance of the error over 
time. It is recommended that some form of DGPS/IRU 
blending (like the one implemented atATL) be 
performed, if possible, to avoid erratic unreliable updates 
of position being presented to pilots on a 
guidance/navigation display. This implementation was 
also ableto tolerate intermittent outages of DGPS while 
still converging to the an accurate position. A detailed 
analysis of the DGPS/IRU data as compared to just 
DGPS data will be published in a separate report. 

All test pilots commented favorably on both the tracking 
of the position updates on the displays with the visual 
scene, and the alignment (on the HUD) of projected 
symbols with physical guidance cues (e.g. painted 
centerlines). This is due to the DGPS/I RU blending 
function performance and the accuracy of the airport 
database. 

4.3.4SURVEILLANCE SYSTEM PERFORMANCE 

The majority of the surveillance data recorded atATL 
will be analyzed and documented in a separate report 
being prepared by the FAA . This includes data from the 



three surveillance sensors employed (ASDE-3, ATIDS 
multi I ateration, and ADS-B) as well as the sensor fusion 
results. Several metrics are being quantified including 
dropouts (and where they occurred), multi-path reports 
(and where they occurred), accuracy (of the three 
surveillance sensors individually and of the fused result), 
latency, and capacity. 

4.3.5 CONTROLLER INTERFACE SYSTEM 
PERFORMANCE 

Performance of the Cl is documented in [16], The 
primary metric of interest is the success rate of the voice 
recognition component. For the entire duration of the 
testing at ATL, the probability of correctly recognizing a 
verbal instruction was 89.1% (490/550). Flowever, 
during the final 12 test runs, the probability was 99.2% 
(123/124). During these runs, it was decided to limit the 
vocabulary of the system to one unique to the ATL 
airport layout. For example, the system was trained to 
recognize only the eight runway names used at ATL 
instead of any runway name. Using this constraint 
significantly improved performance. It should be noted 
that training of the voice system took approximately 20 
minutes for a given individual. 

5.0 CONCL USI ONS 

This activity has demonstrated the potential for using 
technology and a holistic systems approach for improving 
the safety and efficiency of airport surface operations. By 
providing supplemental guidance and situational 
awareness information to both pilots and controllers, 
safety margins can increase as there is more confidence in 
the understanding of the current state of the airport surface. 
In poor visibility, at night, or at unfamiliar airports, this 
supplemental information becomes critical, particularly if 
VFR flow rates are expected to be maintained safely. 
Although this system was not demonstrated in low 
visibility, the questionnaire responses received from the 
test subjects and the visitors from the aviation community 
clearly support this conclusion. In addition, many of the 
proposed operational requirements for A-SM GCS [1] were 
demonstrated. 

This activity also revealed that there can be a near-term 
implementation of many of the demonstrated 
technologies. ASDE-3 and AM ASS are already part of 
the NAS providing surface surveillance information to 
controllers. DGPS has been standardized for Special 
Category I (SCAT-1) landings [8] and is the primary 
sensor for the planned Wide-Area Augmentation System 
(WAAS) and Local Area Augmentation System (LAAS). 
HUDs exist onboard many commercial jets providing 
takeoff and landing guidance to flight crews. I n fact, the 
unit used onboard the B -757 for these trials was 
manufactured for commercial use onboard a Saab 2000 
aircraft. Finally, thousands of M ode-S transponders, 
similar to the one used in this test, are currently onboard 
commercial aircraft. 


A secondary goal of this activity was to validate the 
operational concept. As described earlier, this concept is 
to provide pilots with (1) continuous awareness of 
position on the airport surface, (2) continuous awareness 
of aircraft/obstacle positions, and (3) continuous awareness 
of path/route to follow from current position to the 
destination. The concept provides the controller with 
position reports for all vehicles operating on the airport 
surface, a secondary link with flight crews, and awareness 
of any route deviations. This operational system concept 
was demonstrated and shown to be valid at ATL. This 
implementation augmented available visual cues and 
assumed a ground-based surveillance system at the 
airport, an accurate position sensor onboard, and a 
ground-based route generation method. It should be 
noted, that specific technologies are not being advocated, 
but were merely used as a means to validate the concept. 
Specific technologies were evaluated and may be 
recommended in the future. 

in order for this operational concept to meet its full 
potential, there are technical challenges that still must be 
overcome (e.g. multi-path mitigation, robust voice 
recognition, moving map retrofit, software certification, 
crew roles and procedures, and guidance-to-the-gate). 
These will be addressed as the research continues. Partial 
implementations of this system can be implemented in 
the near-term to provide many benefits with only minimal 
additional technical work. In terms of operations, the 
intent is to design a system that has minimal impact on 
normal operations and procedures. The aids are provided 
to pilots and controllers in such a way as to not increase 
workload and to be used only as needed to supplement, or 
reinforce visual cues. 

The research program deliverable is a set of operational 
and technical requirements for a system that safely enables 
VM C capacities at airports in IM C conditions down to 
Category lll-B . Through this flight test activity, a 
significant step has been taken toward providing that 
deliverable to the aviation community. 
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